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Application Communication 

With U5B (Part 1) 

The Enumeration Process Explained 



Consumers understand how to use U5B technology. Developers must 
understand how it works. This article series is an excellent starting point. 
Mere you learn how a U5B device goes through a number of states as it 
progresses through the enumeration process. 



n the past, when I wanted to give my project 
_ .user I/O through a PC connection, it was as 
easy as 8-N-l. UARTs were an easy interface. 
In fact, a lot of serial communication used an 
8-bit data length with no parity and a single 
stop bit. You could pretty much rely on using 
this default and connection was assured. I liked 
using the serial and parallel ports. Many consid- 
ered these divine in their simplicity. However 
there may be a little confusion with DB25s and 
DE9s, not to mention their s...e...x. I think we 
could have come up with a smaller connection 
form factor to keep laptop manufacturers 
happy, but users seemed to be shouting, "Make 
our lives easier! " The user drives the market. 
And so, we have the universal serial bus (USB). 

For the user, it's (pretty much) plug and play. 
No matter what the peripheral — keyboard, 
mouse, modem, printer, camera, or bulk stor- 
age — it's all the same. Plug it in (a driver might 
have to be selected once) and then it just works, 
first time, every time — or so the dream perpetu- 
ates. Although USB continues to evolve, as a 



user, connecting peripherals has become a no- 
thought process, like tying a shoe lace. We plug 
it in and bing-bong, we're ready to go. 

For a developer, it's a different story. In order 
for every peripheral to play through the stan- 
dard USB connection, it must follow a rigorous 
enumeration process. Enumeration is the 
process of exchanging information that allows 
the host (connection manager) to learn about a 
connected device (peripheral). By asking the 
right questions, the host can determine which 
kind of device is attached and find the right 
driver to load for that device. There are many 
device drivers that come standard with your OS 
(assuming it supports USB). If a standard driver 
does not fit the device, the OS will prompt you 
to supply one. For more information on how a 
device driver is selected, I suggest you pick up a 
copy of Jan Axelson's USB Complete. 

Every USB device will go through a number 
of states as it progresses through the enumera- 
tion process. It begins with an "unattached" 
state. Once a device is plugged into the USB 



Transfer type 


Control 


Bulk 


Interrupt 


Isochronous 


Typical use 


Configuration 


Printer (Delivery time not critical, 
but must get there without 
errors) 


Mouse (Needs to be delivered 
in a timely fashion without 
errors) 


Audio (Needs to be delivered 
on time, but can function with 
sporadic data errors) 


Data 


Message 


Stream 


Stream 


Stream 


Error correction 


Yes 


Yes 


Yes 


No 


Guaranteed delivery rate 


No 


No 


No 


Yes 


Guaranteed latency 


No 


No 


Yes 


Yes 



Table 1— While a USB device could get by using just Control transfers, the Bulk, Interrupt, and Isochronous methods have 
to guarantee specific requirements. 



implemented 
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packet timing here ; but concentrate 
on the transfers themselves. It is suf- 
ficient to say that USB communica- 
tion uses one of four transfer meth- 
ods: control, bulk, interrupt, and 
isochronous. However, all USB com- 
munications must use the control 
transfer to make use of the predefined 
functions (in the USB specifications) 
and perform the enumeration 
process. Table 1 shows typical uses 
for these transfer methods. 

The control transfer is the only 
transfer that can operate bidirectional- 
ly through its particular pipe or con- 
nection. While a pipe is not a physical 
connection, it is an association 
between the host and a device's end- 
point. To start the enumeration 
process, each newly attached device 
must default to a control pipe with an 
endpoint of 0. The host will use this 
default address to communicate with 
this new device and begin the enumer- 
ation process by requesting informa- 
tion. To be able to share the bus with 
all devices, all information to be 
transferred is broken down into one or 
more transactions. Multiple transac- 
tions are necessary when all the infor- 
mation won't fit into a transaction's 
fixed capacity. A transaction can have 
multiple stages, most consisting of a 
token packet, a data packet, and a 
handshake packet (see Table 2). As a 
developer, our requirements have 
been simplified by the introduction 



Register bits 


7 


6 


5 


4 


3 


2 


1 





UCON 




Ping-Pong 
Reset 


Single 
Ended Zero 


Packet Transfer 
Disable 


USB module 
enable 


Resume 
Enable 


USB Suspend 




UCFG 


Eye Pattern 
Enable 


OE Monitor 
Enable 




On-chip Pull-ups 
Enabled 


On-chip Transceiver 
Disable 


Full Speed 
Enable 


PPB CFG1 


PPB CFG2 


USTAT 




ENDP3 


ENDP2 


ENDP1 


ENDPO 


Transaction 
Direction 


Transaction 
PP Bit 




UADDR 


D7 


D6 


D5 


D4 


D3 


D2 


D1 


DO 


UFRML 


D7 


D6 


D5 


D4 


D3 


D2 


D1 


DO 


UFRMH . 








* 




D10 


D9 


D8 


UEPO 








EndPoint Hand- 
shake Enable 


Control EndPoint 
Disable 


Output End- 
point Enable 


Input End- 
point Enable 


Endpoint Stall 
Indicator 






































UEP15 








EndPoint Hand- 
shake Enable 


Control EndPoint m 
Disable 


Output End- 
point Enable 


Input End- 
point Enable 


Endpoint Stall 
Indicator 



Table 5— The first two registers configure the 5IE. The U5TAT register reflects the state of a four-deep FIFO keeping track of transactions. 
Each transaction will have an associated pipe or Endpoint 0:15 and will indicate the direction of the transaction Setup/Output or Input and a 
ping-pong bit (which I'll skip over for now). UADRR is an assignment for future communications by the host once the device has been enu- 
merated through a default assignment of ADDR=0. The UFRMHi register pair is used in isochronous transfers to monitor the present frame 
number. Finally, the last 16 registers, one for each possible endpoint, EMDF0:15, configure how the endpoint is used. ** 
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Transfer type 


Control 


Bulk 


Interrupt 


Isochronous 


Stage 


Setup 


Data (in or 
out) 


Status 


Data fin or 

L/CllCl 111 1 Ul 

out) 


Data (in or 
out) 


Data (in or out) 


Phase 


Token 


Token 


Token 


Token 


Token 


Token 


Data 


Data 


Data 


Data 


Data 


Data 


Handshake 


Handshake 


Handshake 


Handshake 


Handshake 



Table 2— The Control transfer is the only transfer method that consists of multiple Stages: 
5etup, Data (optional), and Status. Every stage requires token, data, and handshaking pack- 
ets (except the Isochronous method). The handshaking phase is not required in an isochro- 
nous transfer since there is no error correction. 



bus, it enters the "attached" state. 
The host can apply power to the 
device if necessary and the device 
enters the "powered" state. After 
retrieving some initial information 
from the device, the host assigns the 
device its own unique address, taking 
the place of its default address of 0. 
Now the device is in the "addressed 
state." Additional information 
retrieval takes place and if the process 
completes properly, the device is now 
in the "configured" state and ready for 
application communication. None of 
this can happen without data being 
passed. So let's start out with a look at 
the transfer process. 

TRANSFERS 

RS-232 communication consists of a 
single type of transfer, where an appli- 
cation passes data back and forth 
between devices at a prearranged pro- 
tocol (normally 8 data bits, 1 stop bit, 
no parity). USB communication has 
two types of transfers: configuring and 



message. In order for this whole idea 
of using a single interface for every 
peripheral to work, the host must be 
able to somehow configure itself based 
on what gets plugged in. So, where the 
user was originally responsible for the 
configuration of the connection by 
setting up both UARTs to the same 
protocol, with USB this configuration 
is handled by the host without user 
intervention. USB has multiple con- 
versations happening simultaneously. 
Not are only configuration and mes- 
sage conversations taking place 
between the host and an attached 
device, but potentially multiple 
devices, all over the same wires. 

A device must know whether the 
configuration or application data 
being passed is for itself or another 
device. This is handled by the USB 
protocol. I've discussed the electrical 
side of USB in a past column (you 
can find a list of my past USB 
columns at the end of this article), so 
I won't discuss connection speed or 




Photo 1 — This view of the Total Phase Data Center application shows the log- 
ging of USB events that have been captured by the Beagle USB 480 protocol 
analyzer. This project has just been plugged into the U5B bus and is beginning 
an enumeration sequence. 



Today, many microcontrollers contain 
a USB peripheral that handles all of the 
USB bus interfacing. This support takes 
care of the hardware and its associated 
bus issues and leaves you to deal with 
the actual packets. I will be using the 
interrupt mode (as opposed to polling) 
for this project, so most of the work will 
take place in response to USB interrupts 
set by the serial interface engine (SIE). 
While this project uses a Microchip 
Technology PIC18F4450, and the infor- 
mation presented here may be specific to 
this manufacturer, the procedural out- 
line should be similar for any micro 
depending on the implementation of its 
USB peripheral. 

I've broken down the registers associ- 
ated with the SIE into two groups: the 
control/status and the interrupt regis- 
ters. The control/status registers are 
basically used to configure the USB SIE. 
I've listed them in Table 3 so you can 
refer to them while we discuss the code 
developed for this project. I've used a 
total of three endpoints. These include 
the default, control endpointO, an input 
endpointl (configured for interrupt 
transfers), and both input and output 
endpoint2s (configured for bulk trans- 
fers). 

The interrupt registers are divided into 
status and error interrupts (see Table 3). 
Most of the action taking place during 
enumeration will be from either the USB 
Reset or the Transaction Complete 
interrupts. 

READY, 5ET, SAMPLE 

Before getting into the actual code, 
let's consider the hardware setup I've 



been using. To monitor USB traffic 
between the host and the device, I 
used a protocol analyzer made by 
Total Phase called the Beagle USB480. 
This product can capture all of the 
USB events that pass through it. Using 
an analyzer helps you keep track of 
the communication packets and 
helps determine what your code is 
reacting to. Photo 1 is the Beagle's 
datacenter view of USB activity when 
I plug my project into the bus 
through the analyzer. Note the top 
two green entries. Here the host is 
resetting the bus and checking the 
attached hardware to determine what 
bus speed to use for communications. 
Then the enumeration process begins 



with the first transfer labeled "Get 
Device Descriptor." 

The enumeration process is like read- 
ing the device's datasheet. Enumeration 
gathers the parameters that describe the 
device, and it begins with the Standard 
Device Descriptor. To retrieve this 
information from the newly attached 
USB device, the host issues a control 
transfer. Refer to Figure 1 for the three 
stages of a control transfer. Note that 
each stage (setup, data, and status) of a 
transfer consists of three transaction 
phases (token, data, and handshake). 
Each transaction ends with the SIE set- 
ting the Transaction Complete interrupt. 

Let's begin with that first transac- 
tion — the setup stage. Figure 2 shows 



Figure 1 — U5B communications 
will consist of i-ms frames that 
can contain many transactions 
between a host and connected 
devices. This figure shows a 
potential sequence of three 
transactions that will complete 
a control transfer within a sin- 
gle frame. The control transfer 
shown here is only an example 
showing events that can occur 
for every transaction. Typical 
control transfers will spread 
across multiple frames. 



USB Reset 
URSTIF 



Start-of-frame 
SOFIF 



SETUP DATA 



From host 


From host 


To host 




SETUP Token 


Data 

Is 


ACK 


SetTRNIF 


From host 


To host 


From host 




IN Token 


Data 


ACK 


SetTRNIF 


From host 


From host 


To host 




OUT Token 


Empty data 


ACK 


— >. SetTRNIF 


h 


Transaction 


H 


^ ' 

Transaction 



complete 



STATUS 



SOF 




1-ms frame 
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the packet protocol for each 
transaction phase on the USB 
bus. The SIE recognizes the 
first transaction as a setup 
token, receives the packet, 
and indicates when it is com- 
plete. The Transaction Com- 
plete interrupt is raised and 
it's up to us to do something 
with it. So where does this 
transaction end up? 



8 bits (low/full) 
32 bits (high) 


8 bits 


7 bits 


4 bits 


5 bits 


N/A 






■ ■ /"lUcy ■ ' '■■■'M 


DATA 


CRC 


' EOP"> -i 


8 bits (low/full) 
32 bits (high) 


8 bits " 


Upto8bytes(low)/1,02 


3 bytes (fuli)/1 ,024 bytes (high) 


5 to 16 bits 


N/A 




DUAL-PORT RAM 

Besides setting the Trans- 
action Complete interrupt, 
the SIE has also placed an entry into 
a 4-byte FIFO called USTAT. This 
information came from the 3-byte 
setup token (highlighted in Photo 1). 
Referring to Figure 2, that's the PID, 
address, and endpoint from the host. 



Figure 2— Here are the three transactions that form a control setup transfer: setup, data, and acknowl- 
edgement. After a specially formatted sync byte, each packet begins with a PID byte. The PID (see 
Table 4) determines the data that follows. 



When you read USTAT, you are get- 
ting the first transaction received by 
the SIE (the next entry in the FIFO 
becomes available as soon as the 
Transaction Complete interrupt is 
cleared). USTAT holds the last end- 



PID Type 


Din fcl ii 

PID Name 


PID<3:0> 


Description 


Token 


GUT 


0001 B 


Address + endpoint number in host-to-function 

Ll dl loaCLKJi l 


IN 


1001B 


Address + endpoint number in function-to-host 
transaction 


SOF 


0101B 


Start-of-frame marker and frame number 


SETUP 


1101B 


Address + endpoint number in host-to-function 
transaction for SETUP to a control pipe 


Data 


DATAO 


0011B 


Data packet PID even 


DATA1 


1011B 


Data packet PID odd 


DATA2 


0111B 


Data packet PID high-speed, high bandwidth 
isochronous transaction in a microframe 


MDATA 


1111B 


Data packet PID high-speed for split and high 
bandwidth isochronous transactions 


Hand- 
shake 


ACK 


001 OB 


Receiver accepts error-free data packet 


NAK 


1010B 


Receiving device cannot accept data or transmit- 
ting device cannot send data 


STALL 


1110B 


Endpoint is halted or a control pipe request is not 
supported 


NYET 


011 0B 


No response yet from receiver 


Special 


PRE 


1100B 


(Token) Host-issued preamble. Enables down- 
stream bus traffic to low-speed devices. 


ERR 


1100B 


(Handshake) Split Transaction Error Handshake 
(reuses PRE value) 


SPLIT 


1000B 


(Token) High-speed Split Transaction Token 


PING 


0100B 


(Token) High-speed flow control probe for a 
bulk/control endpoint 


Reserved 


0000B 


Reserved PID 



Table 4— The PID value is made up of the lower nibble above and an upper nibble, which Is 
simply the complement of the lower nibble, thus holding its own checksum. The 0x2D PID 
(Packet identifier Field in the highlighted transaction in Photo 1) indicates a setup token. 
The following two bytes hold address, endpoint, and CRC information (0x00 and 0x10 = 
ObOOOOOOOO and ObOOOlOOOO = address ObOOOOOOO, endpoint ObOOOO, and crc OblOOO) 
as in Figure 2. 



point received and direction of the 
transaction, in this case endpointO and 
setup/out (bit 7 of the PID). Table 4 
shows the breakdown of the first byte 
of every transaction — the PID. 

The USTAT information refers to a 
special dual-port RAM area that the 
SIE shares with the micro, in this case 
256 bytes in length (0xO400-OxO4FF). 
This area is used for passing all of the 
data that moves through any estab- 
lished pipe, which at this point is only 
the default control pipe between the 
host and endpointO. This area will 
eventually be used for two purposes: 
operational information and data. 

Remember that unlike the single 
data channel for RS-232 communica- 
tions, USB has configuration and mes- 
saging information that shares the 
same bus. Each transaction from the 
SIE uses a set of four registers, one set 
for each of the possible endpoints — 
EPIn0:15 and EPOutO:15. In fact, this 
could be 64 endpoints when using 
ping-pong buffers, but we won't dis- 
cuss this option here. That is a poten- 
tial use of 32 x 4, or 128 registers. 
That's half the allotted dual-port 
RAM. The remaining 128 bytes of 
dual-port RAM would be used as 
buffers for each of these endpoints. 
You can see that space is at a premi- 
um here. This project, as previously 
mentioned, will use a total of five 
endpoints. At this point, the host only 
knows about two: the default control 
pipe to endpointO, which has an input 
endpoint (EPOIn), and an output end- 
point (EPOOut). 

Part of the design process is to allo- 
cate 4 bytes (BDs or Buffer Descrip- 
tors) for each endpoint that will be 



C5 
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0x0400-0; ■ - 



BDOSTAT 




used in your application. Referring 
back to Table 3, UEP0:15 defined if 
and how each of the endpoints will be 
used. While the UEP0 register is the 
default control endpoint and will nor- 
mally have bits D3:l set, it's up to the 
designer to decide if and how the 
remaining endpoints will be used. The 
location of each endpoint has been 
predefined. Since the endpoint alloca- 
tion is 4 bytes for each endpoint, the 
SIE knows where each set of 4 bytes 
begins. In this project, EPOOut is 
placed at the first byte (0x0400, BD0) 
of the dual-port RAM with EPOIn fol- 
lowing at 0x0404 (BD1), as you can 
see in Figure 3. Each byte of the BD 
has an important function. 

Beginning with the last 2 bytes, 
BDnADRH:L (where n - 0-32) form an 
address pointer to USBaB (USBrj 
Buffer) where the endpoint data will 
be found. The size (length) of this 



Figure 3— The four byte groups of Buffer 
Descriptors have predefined locations in the 
dual-port RAM. Their ADRHi registers are 
used to define the actual data buffers used 
by each enabled endpoint. This project uses 
five of the first six buffers. BD4 (EPIln) is 
not used. All RAM after the last enabled BD 
can be used for the actual buffers. In this 
project, U5B0-2 will be 8 bytes in length, 
and U5B3 and U5B5 will be 64 bytes in 
length. Mote that the BD4 registers are 
accounted for and are free RAM; since it 
isn't enabled, no U5B4 Buffer exists. , 

buffer is defined during the design 
process. The size can vary by endpoint 
and is defined in the Descriptor 
Tables. (The Descriptor Tables are the 
device's datasheet; we'll get to these 
later on.) 

The second byte, BDnCNT, indi- 
cates the actual count of pertinent 
data in the buffer. The first byte, BDn- 
STAT, can be a little confusing as it 
has a multiple purpose. Since the 
dual-port RAM can be accessed by the 
SIE and the user application, bit 7 of 
BDnSTAT is a semaphore flag used to 
indicate who owns the BD and 
USBuB. When BDnSTAT.7 = 1, the SIE 
owns the endpoints' RAM and the 
user should not alter the endpoints' 
BDs or USBnB. The SIE will release 
these to the user by clearing BDn- 
STAT.7 when it is finished, signalling 
that there is stuff there for the user. 
When you finish reading from or writ- 
ing to the BDs and USBnB, you give it 
back to the SIE by setting BDnSTAT. 

The rest of the BDnSTAT bits take 
on different meanings depending on 
who owns the BD's dual-port RAM. 
When the SIE hands you these buffers 
(BDriSTAT.7 = 0), the BDnSTAT holds 
the received token's PID (Packet IDen- 
tifier). With this value, you will know 
what to do with the data in the 
USB12B! 

When you hand the BDs and USBnB 
back to the SIE, the BDnSTAT holds 



some housekeeping information. The 
most important housekeeping item is 
the data toggle bit. As a means of 
making sure that stuff is passed back 
and forth between the host and the 
device correctly, data toggling is 
implemented. This method simply 
marks each packet using the data tog- 
gle bit that is flipped after each use. If 
a packet is missed, data toggling will 
be out of sync and the packet can be 
rejected. 

GET OH WITH IT 

The data we found in USTAT tells 
us that we are dealing with EPOOut. 
The associated BD for EPOOut is BD0. 
The four BD0 registers— BDOSTAT, 
BD0CNT, BD0ADRL, and 
BD0ADRH— beginning at address 
0x400 have all we need to know to 
access the first transaction. So assum- 
ing that the USB interrupts have been 
enabled via PIE2.5 along with periph- 
eral and global enable (INTCON. 7:6), 
execution has been tossed to the inter- 
rupt routine. This tests every USB 
interrupt in registers UIE and UIR 
(referring back to Table 5) to see 
which USB interrupts are enabled and 
which needs servicing. For now we are 
interested in only two: Transaction 
Complete and USB Reset. If you are 
clever you may have noticed (from 
Photo 1) that a USB Reset had 
occurred prior to the Get Device 
Descriptor request. 

The host will want a device to inter- 
pret its request correctly, so it will 
begin by putting a device into a 
known state by requesting a reset. The 
USB Reset interrupt requests this, and 
our routine clears out the FIFO, 
UADDR, and UEP0:15 registers. It 
then sets up the BDs for the default 
control endpointO (BD0, EPOOut and 
BD1, EPOIn), endpoint 1, and end- 
point2. This includes the USB0:5 
buffer address pointers for each BD, 



Interrupt register bits 


7 


6 


5 


4 


3 


2 


1 





Status 




Start of frame 


Stall hand- 


Idle detect 


Transaction 


Bus activity 


USB Error 


USB Reset 


UIR and UIE 




token 


shake 




complete 


detect 


condition 




Error 


Bit stuff 






Bus turnaround 


Data field 


CRC16 


CRC5 


PID Check 


UEIRand UEIE 








timeout 


size 






failure 



OS 

m 

I 



O 

SSI 



Table 5— Any interrupt can be enabled via the 'IE registers. Interrupt conditions are revealed via the *IR registers. Bitl of the Status Register 
Is a global Enable and 5tatus bit of the Error registers. ** 
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the third and fourth bytes of each BD 
(BDnADRH:L). The endpoint control 
UEPO is configured for the default, a 
control endpoint using setup, in, and 
out transfers. UEP1 will be output 
(interrupt) transfers only and UEP2 
will use both in and out (bulk) trans- 
fers. Finally, all of the USB interrupts 
are cleared and you exit the interrupt 



Following the flow of USB activity 
based on the Beagle's logging (back in 
Photo 1 ), execution has been directed 
again to the interrupt routine. This 
time it was the Get Device Descriptor 
request that set the Transfer Com- 
plete interrupt. You don't know what 
the request was yet, so you use the 
USTAT register to determine which 
BD to service. The BD's four bytes 



Offset 


Field 


Size (bytes) 


Value 


Description 





bmRequestType 


1 


Bitmap 


Characteristics of request: 










D7: Data transfer direction 










0=Host-to-device 










1 =Device-to-host 










D6..D5: Type 










00=Sta"ndard 










01=Class 










10=Vender 










1 1 =Reserved 










D4..D0: Recipient 








it 


00000=Device 










00001 interface 










00010=Endpoint 










00011 =Other 










00 1 xx-1 1 1 xx=Reserved 


1 


bRequest 


1 


Value 


Specific request 










0=Get Status 










1=Clear Feature 






■ 




2=Reserved 










3=Set Feature 










4-Reserved 










5=Set Address 










6=Get_Descriptor 










7=Set_Descriptor 










8=Set_Configuration 










9=Get_Configuration 










in=npt IntArfarA 

IU~UCl 1 1 I LCI I dLC 










11=Set Interface 










12=Synch_Frame 


2 


wValue 


2 


Value 


Word-sized field that varies accord- 
ing to the request, for descriptors 










Ox0100=Device 










0x02xx=Configuration 










0x03xx=String 










0x0400=lnterface 










0x0500=Endpoint 










Ox0600=Device Qualifier 










0x0700=Other_Speed_Configuration 










0x0800=lnterface Power 


4 


wlndex 


2 


Index or 
Offset 


Word-sized field that varies accord- 
ing to the request. Typically used to 
pass an index or offset 


6 


wLength 


2 


Count 


Number of bytes to transfer if there 
is a Data stage 



Table 6— The U5B Device Request might be the most informative group of Information trans- 
ferred via USB. The first byte completely describes how the request should be handled while 
the second byte defines the request. 




B Engineer's 

est Friend 

Total Phase USB analyzers 
feature real-time display and 
filtering of live USB data 




\eagle USB 12 
Protocol Analy: 
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plus the USTAT register are moved into a set of working 
registers to make them easier to interrogate. This Transfer 
Complete interrupt routine will be handling three of the 
four token PIDs possible in a control transfer, setup, in, 
and out (see Table 2 and Table 4). BDSTAT holds the PID 
that determines which of these to service. The value 
0x2D tells us we need to service a setup token (actually 
it's the "D" that indicates the PID, the "2" is just D's 
complement). 

We branch to the ProcessSetupToken routine to con- 
tinue this interrupt service. BD0ADRH:L shows where to 
find the USBOBuffer, and BDOCNT indicates how many 
characters are significant. USBOBuffer holds the data 
phase of the setup stage. It should be a USB Device 
Request of eight bytes. These eight bytes in the 
USBOBuffer are moved to another set of working registers 
(so we won't need pointers anymore to access them). 
Table 6 shows the format of the USB Device Request. 
Referring back to Photo 1, the second byte in the data 
phase of the setup stage is GetDescriptor (0x06) and the 
host is requesting 0x40 characters. We're through process- 
ing the USBOBuffer, so the BD can be released to the SIE 
(BD0STAT.7 =1). You then clear the packet-transfer dis- 
able that is set by the SIE when a setup token is received 
(UCON.PKTDIS = 0). This action signals the SIE that 
we've serviced it. Now we need to make a branch to han- 
dle the type of descriptor request. This is based on the 
first byte of the data phase (BMREQUEST.6:5), in this case 
it is a Standard Descriptor. 

Within the Standard Descriptor branch there are 10 types 
of requests (offset 1 in Photo 1). We've already determined 
that we need to service the GetDescriptor, however there 
are eight possible descriptor types (offset 2 in Photo 1). 
Luckily, each request doesn't use all of the possible types. 
For this project, we need only three: device, configuration, 
and string descriptors. The upper byte of the wValue in the 
data phase indicates the descriptor type; in this case it is 
Device Descriptor (0x0100). The lower byte will be zero 
unless there are multiple configurations or strings, in 
which case this will indicate an array index. 

We now know that the host is requesting a GetDescrip- 
tor transfer and that we need to send the Standard Device 
Descriptor. This is the first item in a device's datasheet. 
Next month, we'll look at this and the other items that 
make up the datasheet (or USB Descriptors) for this project. 
Keep this column handy, as there is much to refer back to 
next time. I encourage you download a copy of the "Uni- 
versal Serial Bus Revision 2.0" specification. Of particular 
importance is Chapter 9 as this is the essence of communi- 
cation and enumeration. In addition, download the "Class 
Definitions for Communication Devices 1.2." USB devices 
have been grouped by function into classes. Since this pro- 
ject's USB device is of the communication class, you might 
wish to look through the requests and notifications that 
are specific to this kind of device. I'm hopeful this project 
will help you to wade through the USB specifications and 
locate those parts that are meaningful to your particular 
design. H 
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ROM THE BENCH 



by Jeff Bachiochi (USA) 



Application Communication 

With U5B (Part 2) 

The Importance of Descriptors 



You Know how a U5B device goes through a number of states as it progresses 
during the enumeration process. The next topic to understand is the standard 
device descriptor, which is the first item in a device's datasheet. 
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must be the reincarnation of a cat. I'm 
curious about many things. In fact, I've 
used a number of my "nine lives" by letting my 
curiosity take precedence over the self-preserva- 
tion instinct. Do you know anyone who can say 
they've never performed an act of stupidity at 
some point in their life? Somewhere along the 
line, we learn how fragile our bodies are and 
that tempting fate should not be an everyday 
experience. At this point, curiosity takes a 
backseat to personal safely. We are more apt, 
say, to learn about aerodynamics through refer- 
ences and modeling, rather than jumping off a 
cliff with a hang glider. 

I've been interested in USB since it was forced 
upon us years ago. Even though many manufac- 
turers have given us the tools to use it, without 
having to know how it really works, I just can't 
leave it at that. I want to know more about its 
operation. For those of you whomight have 
similar feelings, I hope I can shed a little light 
on this by going through a simple USB project 
that will enumerate and transfer application 
data using assembly language. This project 
began last month. I encourage you to start there 
and get up to speed on the USB hardware 
peripheral — the serial interface engine (SIE) 
built into many of Microchip Technology PIC 
microcontrollers. While each manufacturer may 



arrange things differently, they all must obey 
the same rules. Thus, you should be able to take 
what you learn here and apply it to any micro. 

We left off looking at the start of the enumer- 
ation process as seen from the Beagle USB 480 
protocol analyzer I use to display the bus activi- 
ty between the USB host (my PC) and the pro- 
ject's device circuitry. After forcing a USB reset, 
the host has requested a descriptor. Through the 
SETUP packet received by the SIE, I discovered 
that the host was requesting a standard device 
descriptor (SDD) via a GetDescri ptor transfer. 

We know that the purpose of designing the 
USB interface was to make it user-friendly yet 
universal. That means that the host must be 
able to figure out how to access a device auto- 
matically when a user plugs it into the bus. To 
do this, a device must be able to answer all the 
questions the host will ask it. These questions 
have been predetermined by the USB specifica- 
tions. So, as a device, we need to be ready to 
respond with the answers. The answers come 
from USB descriptors, a collection of informa- 
tion describing the device. Each descriptor uses 
an identical format to simplify the exchange of 
information. A descriptor begins with a length 
byte followed by a type byte. Let's begin with 
the descriptors, as defined in this project, to 
describe its configuration to the host, the 
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Standard Device Descriptor 


Offset 


Field 


Size 


Format 


Description 


Project Value 





bLength 


1 


Number 


Descriptor length in bytes 


0x12 


1 


bDescriptorType 


1 


Constant 


DEVICE 


0x01 


2 


bcdUSB 


2 


BCD 


USB Specification revision 


0x0200 


4 


bDeviceClass 


2 


Class 


Class Code 


0x02 


5 


bDeviceSubClass 


2 


Subclass 


Sub Class Code 


0x00 


6 


bDeviceProtocol 


1 


Protocol 


Protocol Code 


0x00 


7 


bMaxPacketSizeO 


1 


Number 


Maximum packet size EPO 


0x08 


8 


idVendor 


1 


ID 


Vendor ID 


0x04D8 


10 


idProduct 


1 


ID 


Product ID 


0xFE96 


12 


bed Device 


1 


BCD 


Device Revision 


0x0000 


14 


iManufacturer 


1 


Index 


Manufacturer String Index 


0x01 


15 


iProduct 


2 


Index 


Product String Index 


0x02 


16 


iSerialNumber 


1 


Index 


Serial Number String Index 


0x00 


17 


bNumConfigurations 


1 


Number 


Maximum Device Configurations 


0x01 



Table 1— The standard device descriptor describes general information about the device. It indicates to 
the host how many configurations it should look for that are associated with the device. ' 



device descriptor, the configuration 
descriptor, and the string descriptor. 

5DD 

A USB device has only, one SDD as 
it is a global description of the device 
and all its configurations. Table 1 
shows that this descriptor contains 
the version number of the USB specifi- 
cations that it conforms to, so the 
host will understand the rules it can 
play by. 

Next are the device's class and sub- 
class. These define the kind of 
device — in our case, it is the commu- 
nications device class, covering 
telecommunications and networking 
devices. The communication device 
class has no subclass or device proto- 
col, so these bytes are zero. The pack- 
et size byte tells the host a packet's 
maximum size. For EndPointO, that's 
8, 16, 32, or 64 bytes. 

Next, the device descriptor lists the 
vendor ID (that's Microchip Technolo- 
gy), the product ID (that's mine), and a 
release or version number for my 
application. Because all this is kind of 
cryptic, the descriptor includes a num- 
ber of bytes that can point to string 
descriptors that will describe the man- 
ufacturer, the product, and the serial 
number using ASCII text. These may 
show up in various places on your PC 
when installing drivers or viewing sys- 
tem information. Finally, one last byte 
indicates the number of configurations 



your device supports. In this project, 
we have just one. 

My SDD is 0x12 bytes long, so how 
can the host get this if I'm using a 
maximum packet size of eight? If you 
refer back to the first part of this 
series, you'll see that the host follows 
itsGetDescriptor set-up transaction 
with additional "in" token requests 
until it has received all it requires. But 
hold on to that thought; we haven't 
discussed the "in" and "out" token 
yet. 

5CD 

Unlike the SDD, there may be more 
than one standard configuration 
descriptor (SCD). Remember, the 
number of configurations was defined 
back in the last byte of the SDD. In 
this case, we're just dealing with a 
single configuration; therefore, we 
need only one configuration descrip- 
tor. The configuration descriptor is very 
complex. It is a container, if you will, 
for all the interface descriptors associat- 
ed with this configuration. It uses the 
standard descriptor format so the host 
knows the descriptor's type and size by 
the first 2 bytes (see the table posted on 
the Chcuit Cellar FTP site). 

The SCD's next 2 bytes define the 
total size of all the descriptors associ- 
ated with this configuration. Follow- 
ing this is the actual number of inter- 
faces supported by this configuration, 
the number of this configuration, and 



the index of any string 
descriptor describing this 
interface. The last 2 bytes 
define the attributes of the 
configuration (self -powered 
or supports remote wakeup) 
and the maximum power 
consumption (if it were to 
require power through the 
USB connector). 

In this project, the host 
discovers that this configu- 
ration ( 1 ) has two interfaces 
associated with it. It also 
finds that the device is self- 
powered and supports 
remote wakeup. If its local 
power is removed, it would 
require 100 mA. While the 
host discovered this config- 
uration descriptor's length 
is only 9 bytes, it knew to look for a 
total length value within this descrip- 
tor. It can continue to read in addi- 
tional transactions (using the "in" 
token) until it has all of this informa- 
tion. The host can then break down 
this data into additional descriptors 
looking for more information on each 
of the two interfaces. 

Appended to, and as part of, the 
total SCD, are any additional descrip- 
tors that are required to fully define 
the device's configuration. Here we 
have two interfaces to define, and 
each will have its own interface 
descriptor. The first interface (inter- 
face descriptor 0) has rio alternative 
setting — so its value is zero (the first 
and only) — and the number of end- 
points used for the interface is one. 
Also within the interface descriptor 
are communication interface class (2), 
subclass (2), and protocol (1) values. In 
this descriptor, the host learns that 
interface is of the communication 
class using the abstract control model 
having one endpoint. 

We know that USB devices require 
specific device drivers to be loaded on 
the PC. To support all possible USB 
devices, this driver would be mam- 
moth. So, the driver that gets loaded for 
each device contains only the subset 
necessary for its associated device. The 
driver gives the host the ability to 

particular device. The subclass 2 
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Standard String DescriptorO 



Offset 


Field 


Size 


Format 


Description 


Project Value 





bLength 


1 


Number 


Descriptor length in bytes 


0x04 


1 


bDesriptorType 


1 


Constant 


STRING 


0x03 


2 


wLANGID 


2 


Number 


Country Code 


0x0409 



Standard String Descriptor! 



Offset 


Field 


Size 


Format 


Description 


Project Value 





bLength 


1 


Number 


Descriptor length in bytes 


0x36 


1 


bDesriptorType 


1 


Constant 


STRING 


0x03 


2 


bString 


N 


Number 


Text 


"Microchip Technology, Inc." 



o 



I 

O 
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Standard String Descriptor 



Offset 


Field 


Size 


Format 


Description 


Project Value 





bLength 


1 


Number 


Descriptor length in bytes 


0x4C 


1 


bDesriptorType 


1 


Constant 


STRING 


0x03 


2 


bString 


N 


Number 


Text 


"Imagine That 

(www.imaginethatnow.com)" 



Table 2— The standard string descriptors have two formats. 5tring0 defines the language used by the host to talk to the user. The remaining 
strings contain A5CII text presented In a UNICODE presented string. 



(abstract control model) has its own set 
of descriptors that are used to help 
describe its functions through an inter- 
face. There are 25 subtype descriptors for 
the communications class. We will be 
using four for this project: header, call 
management (CM), abstract control 
management (ACM), and the union 
functional descriptor. You can read 
about all of them in the communication 
class specifications. The header descrip- 
tor indicates the version of the specifica- 
tions that the interface is adhering to. 
CM defines the caU-handling capabili- 
ties — and there are none, in this case. 
The ACM identifies the capabilities of 
the interface. These include: network 
connection support; sending break, line, 
and serial states; and COMM features. 
Finally, the union descriptor defines the 
master interface (interface in this case) 
and the subordinate interfaces. In this 
instance, there is only one other inter- 
face — interface 1. 

Following the subclass descriptors for 
this interface, you must include the end- 
point descriptors for this interface. One 
endpoint is for this interface and its 
descriptor identifies the actual endpoint 
(EPlIn) using an interrupt transfer type. 
This short descriptor also includes the 
packet size (64 bytes) and how often the 
host will poll for data (2 ms). 

The second interface (interface 
descriptor 1 ) has no alternative set- 
ting, so its value is zero (the first and 



only) and the number of endpoints 
used for the interface (two endpoints 
here). The data interface class (10) has 
no subclass and uses no protocol, so 
these values are zero. In this descrip- 
tor, the host learns that interface 1 is 
of the data class using no specific pro- 
tocol and having two endpoints. This 
interface has no additional descriptors 
other than the two specified endpoint 
descriptors. One endpoint is defined 
as using endpoint (EP20ut) using a 
bulk transfer type. The second end- 
point is defined as using endpoint 
(EP2In) using a bulk transfer type. 
Both endpoints will use a packet size 
of 64 bytes and request polls whenev- 
er there is bandwidth. 

S5D 

If any optional standard string 
descriptors (SSD) are used, the first 
descriptor must identify the language 
or languages (see Table 2). The 16-bit 
LANGIDs2 defines how the host 
should present text to user (i.e., "Hit a 
key to continue"). The remaining 
strings can give the user an ASCII text 
description of some cryptic value with- 
in the associated descriptor. 

In this project, the second SSD (1) is 
associated with the Manufacturer ID in 
the SDD and the text reads "Microchip 
Technology, Inc." The third SSD (2) is 
associated with the product ID in the 
SDD and the text reads "Imagine 
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That (www.imaginethatnow.com)." 

RETRIEVE DESCRIPTORS 

I reprinted the first page of transac- 
tions as captured by the USB 480 Proto- 
col Analyzer in Photo 1 because it 
demonstrates how the host interacts 
with this device when plugged into the 
USB and enumeration begins. We left 
off last month with the SIE setting the 
transaction complete interrupt after 
receiving the set-up token via EPO. The 
buffer descriptor (BDO) associated with 
default endpoint (EPOOut) pointed us to 
the 8-byte EPOOut buffer that held the 
packet data received by the SIE. Upon 
moving and interrogating the data, it 
was found to be requesting 64 charac- 
ters via a GetDescriptor request (0x80). 
The descriptor data we discussed above 
has been placed at the top of the pro- 
gram memory space by the assembler, 
so we know where it can be found. 

You must prepare an 8-byte packet 
response for the SIE before clearing the 
interrupt. Once you clear the interrupt, 
the SIE will acknowledge the SETUP 
packet and the host will send an IN 
packet to get our data. You best be ready. 
•To get the requested information, 
USB_desc_ptr is preloaded with the off- 
set address of the character we want 
from the descriptor table. A call to the 
Descriptor routine loads the address of 
the beginning of the descriptor table into 
a table pointer that will fetch characters 
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from the program memory space. The 
offset is added to the table pointer, a 
character is fetched from that address, 
and returned. The character can be then 
transferred to the EPOIn buffer and the 
next character sought. When Epoln 
buffer is filled we can leave the interrupt 
routine and clear the interrupt, the SIE 
acknowledges the host. 

Refer to Photo la. The host has con- 
tinued with an IN token. The SIE will 
again set the transaction complete inter- 
rupt after sending the data we preloaded 
into EPOIn buffer. Note that the 8-byte 
DATA1 packet of the IN token has the 
first eight characters of the SDD. This 
time the interrupt routine will discover 
an IN token request from the USTAT 
and branch to the Process I nToken 
routine. Since I stored the SETUP 
token's GetDescriptor request in 
USB_dev_req, I know how I got here and 
must continue to preload 8-byte packets 
of data into the EPOIn buffer until all the 
requested data has been sent, I run out 
of data to send, or the request is can- 
celled by a new SETUP token. 

As you can see in Photo la, notice 
that after the host acknowledged the 
receipt of the first IN data, it sent an 
OUT token. This is an acknowledgment 
that the transfer request is complete. It 



decided it has what it wants. Not only 
did it find out what the maximum pack- 
et size was (0x08), but also that the SDD 
is 0x12 bytes in length (no sense asking 
for more than that). 

Note that this GetDeviceDescriptor 
transfer contained three stages: a setup 
transaction (in this case one), a data 
transaction, and a status transaction. 
Each transaction stage has a token 
phase, a data phase, and a handshake 
phase (see Figure 1 ). 

ADDRESS STATE 

Up to this point, the communication 
has taken place on the default address 
UADDR=0. The host is now ready to 
assign the device a real address. The 
host sends a SETUP token. The receipt 
of the token by the device's SIE causes 
another transaction complete interrupt. 
USTAT reveals it was via EPOOut. By 
processing the EPOOut Buffer, we find 
the 8-byte packet contains a 
SET_ADDRESS request (0x00) and the 
new address is 0x06. While you might 
be tempted to change UADDR immedi- 
ately, hold on. Since this is only the 
SETUP stage of this transfer, we must 
continue using the old address until the 
transfer is complete. This is the only 
time when you need to finish things 



before making use of the data received. 
Since this request has no DATA stage, 
we just preload a zero-length packet into 
the EPOIn Buffer and it is used as the 
HANDSHAKE stage. We exit the inter- 
rupt routine, clearing the interrupt and 
the SEE ACK is the SETUP token. 

The host sends an IN token (the 
beginning of the HANDSHAKE stage), 
the SEE receives the request and sends 
the EPOIN Buffer, and sets the transac- 
tion complete interrupt. USTAT reveals 
it was via EPOIn. Since we stored the 
SETUP token's SETADDRESS request 
in USB_dev_req, we know how we got 
here. There is nothing expected as this is 
the end of the SetAddress request and all 
transactions are complete. We are now 
clear to change UADDR to 0x06. And, 
don't forget to reset our USB_dev_req to 
OxFF (NO_REQUEST). Once we leave 
the interrupt routine, clearing the inter- 
rupt flag, we have transitioned into the 
ADDRESS_STATE. 

CONFIGURE STATE 

Note that the next SETUP token 
(and all subsequent tokens) are sent to 
the new address 0x06. Now the device 
pays attention only to those tokens 
containing the new address. This new 
SETUP token is again requesting the 




Photo la— The Beagle protocol analyzer's capture of the U5B traffic clearly shows the transfer requests of a device beginning the enumera- 
tion process. Every device begins with a default address of and is reassigned a new address by the 5erAddress request seen here, b— The 
enumeration process ends when the host requests that a device be configured to one of Its declared configurations. This project has a single 
configuration. Once configured, the host will begin polling for information according to the Endpolnt Descriptors, as seen at the bottom here 
as IIIJIAKs to EP2 and EP1. 
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Figure 1— This is a 
potential sequence 
of three transactions 
that will complete a 
control transfer. 
Each transaction or 
stage consists of a 
Token, Data, and 
Acknowledgement 
Phase or Packet. 



From host 



From host 



To host 



USB Reset 
URSTIF 



Start-of-frame 
SOFIF 



SETUP Token 



Data 



From host To host From host 



IN Token 



Data 



ACK 



From host From host 



To host 



OUT Token Empty data 



ACK 



Set TRNIF 



Set TRN1F 



Set TRNIF 



Transaction 



Transaction 



RESET 



SETUP 



DATA 



STATUS 



it 



SOF 



Control transfer* 



1-ms frame 



"The control transfer shown here is only an example showing events that can occur for every transaction. 
Typical control transfers will spread across multiple frames 
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GetDevi ceDescri ptor. This time it is only asking for 
0x12 bytes. The host will continue to gain knowledge about 
the device by sending GetConf i gurati onDescri ptor and 
GetStringDescri ptor requests. Once it knows every- 
thing, the host will request aSetConfi gurati on and final- 
ly GetLineCodi ng and SetControl Li neState via the 
class-specific requests. 

The SetConfiguration request gives the device permission 
to use a specific configuration. In this case, we have defined 
only one. The configuration uses two interfaces and now we 
set them up using EPlIn as an ACM interface using inter- 
rupt transfers (the control interface) and EP2In and EP20ut 
as the data interface using bulk transfers. The class-specific 
GetLi neCodi ng request informs the host that our (virtual) 
UART is set to receive 8 data bits, with 1 stop bit, and no 
parity at a data rate of 115,200 bps. These are values I chose 
and stored in initialized variables so that they can be 
recalled and changed if necessary. I could set up the micro- 
controller's (physical) UART and this project would be a 
USB-to-UART interface, but that is an application left up to 
you. The SetControl LineState request presents the 
device with RTS and DTR states, which are controlled by 
the host. 

The device is now in the CONFIGURE_STATE. It will be 
listed as a (virtual) COMM port in any application running 
on the PC that can use a serial port for data communication. 
The host starts to poll both interfaces of the device. It is 
polling EPlIn looking for any control information that the 
device might want to convey to the host. It is also looking 
for any data on EP2In that the device may want to transfer 
to the host. The device is happy with the status quo and 
has no information to pass on, so the SIE has not been given 
control over any of the IN endpoints. It will NAK all polls, 
which tells the host that it's busy and to try again later. By 
"later" I mean (as defined in the standard endpoint descrip- 
tor) every two frames (2 ms) for the interrupt endpoint and 
whenever there is room for the bulk endpoint. 

When an application on the PC selects this COMM port 
for use, things begin to happen once again. In my next arti- 
cle, I'll look at the two conversations that take place 
through the configured device's newly established endpoints, 
EP1 and EP2. i 
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